Notifying maintainers:
@jyrkiwahlstedt for port postgresql13-doc, postgresql13-server, postgresql14-doc, postgresql14-server, postgresql15-doc, postgresql15-server.
@barracuda156 for port postgresql13, postgresql14, postgresql15, postgresql16-server, postgresql16, postgresql17-server, postgresql17.

@dgilman postgresql16 and postgresql17 need to depend on MacPorts perl5, since they require at least 5.14, while 10.6, for example, has 5.10. I am not sure about 10.7.

P. S. It seems from variant existence that perl is optional, but it is not, or otherwise argument is wrong and has no effect.
Merely activating perl5 port works, no special arguments or env variables needed. I.e. depends_build should suffice.

I see that postgresql17 gained a requirement on perl 5.14 but don't see the same comment in postgresql16's docs https://www.postgresql.org/docs/16/install-requirements.html

I see that postgresql17 gained a requirement on perl 5.14 but don't see the same comment in postgresql16's docs https://www.postgresql.org/docs/16/install-requirements.html

@dgilman As a matter of fact, it failed with the system perl 5.10. Possibly requirement is lower than 5.14, but if it is not higher than 5.10, then it is a bug, and it should be.
(Of course, there is no need to add a dependency on perl5 across the board, only old systems need it.)

postgresql16 has been in MacPorts for ~1.5 years, are you saying you see a regression with the 16.6 -> 16.7 change, or it has never worked on old macs?

@dgilman I have no idea when this appeared, but configure script of 16.7 has this:

if test "$PERL"; then
  pgac_perl_version=`$PERL -v 2>/dev/null | sed -n 's/This is perl.*v[a-z ]*\([0-9]\.[0-9][0-9.]*\).*$/\1/p'`
  { $as_echo "$as_me:${as_lineno-$LINENO}: using perl $pgac_perl_version" >&5
$as_echo "$as_me: using perl $pgac_perl_version" >&6;}
  if echo "$pgac_perl_version" | sed 's/[.a-z_]/ /g' | \
    $AWK '{ if ($1 == 5 && ($2 >= 14)) exit 1; else exit 0;}'
  then
    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING:
*** The installed version of Perl, $PERL, is too old to use with PostgreSQL.
*** Perl version 5.14 or later is required, but this is $pgac_perl_version." >&5
$as_echo "$as_me: WARNING:
*** The installed version of Perl, $PERL, is too old to use with PostgreSQL.
*** Perl version 5.14 or later is required, but this is $pgac_perl_version." >&2;}
    PERL=""
  fi
fi

I see that, and I opened the bug for the docs in upstream.

Honestly, if they're going to start requiring perl for even tarball builds, I'm not opposed to putting the dependency on perl for all versions of macOS. Perl 5.14 came out in 2011 so 10.7, possibly 10.8 needs it. But for everyone else, might as well use a still supported perl?

Pre-16 versions build normally with system perl 5.10, perhaps on newer systems 16+ will also build with system perl (provided it is at least 5.14). At the same time, it is hard to imagine MacPorts installation without default perl, so perhaps overhead is negligible even if a dependency is added across the board.

Looking at the configure script you quoted, it only prints a warning and nulls out the PERL variable. The part below it (not quoted) prints out a further warning if PERL is empty. The build does fail if $with_perl is set and PERL is empty, but MacPorts would only hit that if you're building the +perl variant. But if you were doing a +perl build it would have brought in MacPorts perl as a dependency already. So where exactly is postgresql16 failing with old perl?

@dgilman I am away from the hardware, so can’t check. This is supposed to be reproducible on x86, or if it is not by some miracle, no need to bother fixing it. Maybe perl is enabled by default?

Can you confirm exactly versions of postgresql you test built on what versions of macos?

Maybe it is reproducible on x86 but that doesn't matter, I don't have any old hardware. I am reliant on you and your feedback to make fixes for old systems. You said that postgresql16 doesn't build with old perl, can you provide more details? I had opened a ticket to upstream to address this issue based on your original feedback and now we need to sort out what's going on.

@dgilman I was building your updates in a row starting from 13 up, doing a clean build (in a sense of deactivating all ports first), and 13–15 built normally, 16–17 failed with ”no perl found”. The failure looked similar or identical, and since it was straightforward, I did not dig into logs further. It is possible that only one failure explicitly mentioned 5.14 requirement, but both failed because of not finding a satisfactory perl. Once I activated perl5 port, both versions built normally. It was on 10.6.8 (ppc irrelevant, since perl version is identical with x86).